OpenSSH 10.4p1 uplift by andrewyounkers · Pull Request #198 · open-quantum-safe/openssh

andrewyounkers · 2026-08-11T16:36:22Z

This PR merges in upstream commits from the OpenSSH-portable V_10_4_P1 tag by running a git merge V_10_4_P1. The main changes that I noticed during the uplift causing conflicts had to do with the upstream addition of enabling the ssh-mldsa44-ed25519 hybrid signature algorithm.

All merge conflict resolutions are shown in commit: 1dc4dc1. I used the following methodology to resolve all merge conflicts

Accept current to preserve OQS specific logic
Accept any combinations needed to bring in updated upstream code but keep OQS specific code
Accept incoming for all other conflicts to bring in new upstream logic

In the past OQS-SSH has rejected upstream OpenSSH hybrid PQ algorithms due to them already being implemented in the project, but this is a case where the upstream is adding a new algorithm the project doesn't already support. Since there was no conflict in bringing in this new algorithm, I kept the upstream code enabled and as such ssh-mldsa44-ed25519@openssh.com is now available in this project. I added a note to the README to address this in the following commit: 1ef3c3a.

This was missed after the file was updated, but nobody noticed it until now.

-> uintXX_t OpenBSD-Commit-ID: 6d5e80bd6f29a9db18b18beeb1cbe5423b59de44

~I escape OK dtucker@ OpenBSD-Commit-ID: 695c1a09c4cc8b417a1bd3eb207b0cc7fa831c7a

Fixes interactive vs bulk IPQoS for client->server traffic. ok job@ OpenBSD-Commit-ID: 34f5131face8d6dc4ae6955196e5fcafb3570cfe

OpenSSL 4 removes support for ENGINE, but it provides no-op stubs for the ENGINE functions in addition to setting OPENSSL_NO_ENGINE. The presence of the stubs fooled the old configure test, so if someone tried --with-ssl-engine with OpenSSL 4.0.0 it'd try but fail at build time. Explicitly check for OPENSSL_NO_ENGINE. before trying to enable ENGINE support. bz#3952.

Recently Cygwin imported changes from Fedora which disable SHA1 signatures by default. This breaks the unit tests (and a couple of regression tests), so set rh-allow-sha1-signatures=yes in the OpenSSL config to re-enable them.

On sparc64 ssh/unittests/kex fails to build with: usr.bin/ssh/libcrux_mlkem768_sha3.h:8196: warning: inlining failed in call to 'libcrux_ml_kem_polynomial_ZERO_89_ea': --param max-inline-insns-single limit reached OK djm@ (long time ago) reminded by tb@ OpenBSD-Regress-ID: c32094e3436536474039a4aeefabdbf0bd826554

sshd_config instead of supported key types, which is almost but not completely correct. OpenBSD-Regress-ID: 43c3b348576900f3e710bff5d6a87f0e803c5b3d

channels does OK djm@ OpenBSD-Commit-ID: fa035fb19b74571992fa3adca4396a4c572a7a8a

so it can be cleaned up at exit. Reported by / tested by David Krause, ok markus@ OpenBSD-Commit-ID: b45d740e9a63dec0fad436ed78f6912b39f0cd53

fortify warnings on android. bz3954 OpenBSD-Commit-ID: 82224426b2ee989c68f305caa50aa3d3b4993a84

Add missing SSHD_CONFOPTS="UsePam yes" to the solaris PAM test step so it actually tests PAM functionality instead of re-running the default tests with a PAM-enabled binary.

we don't use the in OpenSSH and some compilers throw warnings compiling them that break -Werror

There's no point rerunning unit tests.

- Set up and run tests with SUDO. - Set random password to use for password & kbdint auth tests. - Only run t-exec when re-testing with PAM, don't rerun unit tests. - When testing PAM builds, test with and without UsePAM.

problems 1) Remove an early failure return for GSSAPI authentication attempts made for invalid accounts that yielded different behaviour for valid vs invalid accounts. 2) Fix a situation where some GSSAPI requestes were not correctly subjected to MaxAuthTries. 3) Fix a moderate pre-authentication resource DoS related to #2. Add missing logging for error cases. Report and fixes from Manfred Kaiser, milCERT AT OpenBSD-Commit-ID: ca0acdd64eea435d6f89534538a9eb404a5629d3

OpenBSD-Commit-ID: ce7b0749e5139c70410ee92a13d368d7d34262b5

refactoring servconf.c bz3974 patch from Colin Watson OpenBSD-Commit-ID: be39ad3dbe36d9ecdb86f3811da5dfbdc9bcb1e6

This is documented to be allowed, and was up until 10.4p1 when a transcription error in the config handling rework reverted it to global-only, ie not allowed inside Match. bz#3987.

…_4_uplift

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

baentsch · 2026-08-12T05:44:58Z

In the past OQS-SSH has rejected upstream OpenSSH hybrid PQ algorithms due to them already being implemented in the project,

Thanks for pointing this out @andrewyounkers ! This in my eyes is a statement and stance that surprises me: Can you point to such instances? What's your personal thought around this: Are you of the opinion that OQS has the resources and development principles allowing it to replace (presumably) well-maintained upstream code?

fwiw, in oqs-provider (for openssl) I took the exact opposite stance, namely to remove PQ algs (and of course also their hybrids) that the upstream began to carry on the grounds that the upstream is the professionally maintained crypto lib and OQS doesn't have resources nor development principles warranting it over-ruling such well-maintained upstream code.

On the alg itself,

the upstream addition of enabling the ssh-mldsa44-ed25519 hybrid signature algorithm

allow me to ask the question what this update then removes from the upstream: The complete crypto, i.e., also an ML-DSA from the upstream, or just the hybrid-ization, i.e., ML-DSA still comes from the upstream? If the former, are there no other hybrids (that then would differ in terms of where the PQ logic comes from)?

FWIW, for openssl I began work on a provider that does hybrid-ization independent of the original crypto provider to still allow PQ experimentation -- but not by-default "overrule" the upstream: Might the same approach be worth-while considering here?

All told, I see the principle

Accept current to preserve OQS specific logic

highly skeptical and wouldn't follow it nor approve a PR doing so. Good I have not been asked to do so :-). So just take this statement as a correction of possibly committed prior crimes (should I have set the precedent you mentioned above of rejecting upstream OpenSSH hybrid PQ algorithms: I am willing to stand corrected when I see I made mistakes).

andrewyounkers · 2026-08-12T17:19:59Z

In the past OQS-SSH has rejected upstream OpenSSH hybrid PQ algorithms due to them already being implemented in the project,

Thanks for pointing this out @andrewyounkers ! This in my eyes is a statement and stance that surprises me: Can you point to such instances? What's your personal thought around this: Are you of the opinion that OQS has the resources and development principles allowing it to replace (presumably) well-maintained upstream code?

The two examples that I was referencing were sntrup761x25519-sha512@openssh.com and mlkem768x25519-sha256. The openssh implementation of these algorithms are disabled in defines.h and OQS-SSH/liboqs logic is used instead to provide these algorithms. This logic was in place before my involvement with OQS-SSH so I had preserved it throughout uplifts.

I am personally of the opinion to prefer the upstream code for the reason you mentioned of it being well-maintained code. I am willing to swap these algorithms to the OpenSSH implementation in this PR for all the reasons you provided above and carry on with the precedent set by the oqs-provider.

fwiw, in oqs-provider (for openssl) I took the exact opposite stance, namely to remove PQ algs (and of course also their hybrids) that the upstream began to carry on the grounds that the upstream is the professionally maintained crypto lib and OQS doesn't have resources nor development principles warranting it over-ruling such well-maintained upstream code.

On the alg itself,

the upstream addition of enabling the ssh-mldsa44-ed25519 hybrid signature algorithm

allow me to ask the question what this update then removes from the upstream: The complete crypto, i.e., also an ML-DSA from the upstream, or just the hybrid-ization, i.e., ML-DSA still comes from the upstream? If the former, are there no other hybrids (that then would differ in terms of where the PQ logic comes from)?

This update doesn't replace the complete crypto implementation of ssh-mldsa44-ed25519 from the upstream. The upstream calls OpenSSH's bundled libcrux ML-DSA implementation where all other signature algorithms call liboqs. If the above algorithms were swapped to enable the OpenSSH code, only the three algorithms mentioned in this comment would differ in terms of where the PQ logic comes from.

FWIW, for openssl I began work on a provider that does hybrid-ization independent of the original crypto provider to still allow PQ experimentation -- but not by-default "overrule" the upstream: Might the same approach be worth-while considering here?

I do think the same approach of the hybrid provider would be worthwhile here especially as more PQ algorithms become supported by OpenSSH. I can make an issue for tracking this feature in the long-term. Moving forward until that is implemented, I think it is best to prefer the upstream algorithm when OpenSSH makes one available.

All told, I see the principle

Accept current to preserve OQS specific logic

highly skeptical and wouldn't follow it nor approve a PR doing so. Good I have not been asked to do so :-). So just take this statement as a correction of possibly committed prior crimes (should I have set the precedent you mentioned above of rejecting upstream OpenSSH hybrid PQ algorithms: I am willing to stand corrected when I see I made mistakes).

Thank you @baentsch for the thoughtful comments, I hope this addressed your questions but will be able to further discuss if there is a follow-up. I will include a reply to the last section in a new comment as my response is a bit long - sorry :-)

andrewyounkers · 2026-08-12T17:20:27Z

@baentsch In regards to the comments around " Accept current to preserve OQS specific logic", I would like to clarify what I meant by that bullet point and seek guidance for the future.

When resolving merge conflicts my priority is to always bring in the new upstream code first. If there is OQS specific logic that after investigating needs to be kept, I bring in a combination of the changes to get the incoming logic without breaking the OQS specific logic in place. I will note there are not very many of these cases.

Majority of the merge conflicts that I have experienced during the uplifts come from OQS code surrounded by ///// OQS_TEMPLATE_FRAGMENT comments or the OQS specific case statement CASE_KEY_OQS:. Most of what I have seen is that the incoming changes just remove these sections, so accepting "current" for these conflicts just preserves what is needed for OQS algorithms without losing any new upstream logic. If there are upstream changes in the conflicts surrounding the OQS code, the new code gets brought in as a combination. This is what I was referencing in the above bullet point, which I can now see wasn't a very good or clear description on my end.

With this explanation does it alleviate any of your concerns? If this still is troubling is there a better process that I can follow in future uplifts? I apologize for not being more clear in my description, and will include more thorough explanations of the merge conflict resolution process in future uplift PRs.

This commit addresses PR comments in open-quantum-safe#198. The changes here are to remove OQS implementations and generation of sntrup761x25519-sha512@openssh.com and mlkem768x25519-sha256 in favor of the upstream OpenSSH's implementaion of these algorithms. Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

alharrison · 2026-09-25T15:57:20Z

@baentsch Not trying to rush, just hoping to make sure this is appearing in your inbox after our conversation earlier this week. Thank you!

baentsch · 2026-09-25T16:35:53Z

Apologies @andrewyounkers , this indeed dropped off my radar. So here we go:

I am willing to swap these algorithms to the OpenSSH implementation in this PR for all the reasons you provided above and carry on with the precedent set by the oqs-provider

Thanks very much: That'd be great.

I can make an issue for tracking this feature in the long-term. Moving forward until that is implemented, I think it is best to prefer the upstream algorithm when OpenSSH makes one available.

Both perfectly sensible and in line with my thinking.

With this explanation does it alleviate any of your concerns?

Yes, it does. Thanks! Please let me know when I should review the key files I can meaningfully review (README and testing logic).

andrewyounkers · 2026-09-28T14:32:48Z

@baentsch thank you for your reply. I have created issue #199 for a future effort to support the hybrid-provider in OQS-SSH.

All files in this PR are ready for review now. The README has a small amount of changes but will need review to ensure the wording about support for upstream PQ algorithms aligns with the OQS project. There were no test changes required besides new upstream code being merged in, but I have verified all upstream supported PQ algorithms are being tested in the CI run.

Commit 31f2cc0 is the other area I would identify for meaningful review. No upstream changes from the uplift drove changes in OQS-SSH besides what is represented in this commit.

Commit 1dc4dc1 contains all merge conflict resolutions, but as mentioned above this is mostly just preserving OQS code surrounded by ///// OQS_TEMPLATE_FRAGMENT comments

baentsch

Mostly questions on this commit

baentsch · 2026-10-06T13:55:37Z

 #endif /* OPENSSL_HAS_ECC */
 #endif /* WITH_OPENSSL */
 	server2->kex->kex[KEX_C25519_SHA256] = kex_gen_server;
+	server2->kex->kex[KEX_KEM_SNTRUP761X25519_SHA512] = kex_gen_server;


bespoke test code for algorithm(s): why?

This change brings back in the upstream logic explicitly testing the upstream PQ algs. When reviewing this it appears to me no OQS PQ algorithms are being tested currently, so I added templating logic for this in 73875d4. If it seems reasonable I will merge in this logic, or revert if not.

baentsch · 2026-10-06T13:58:13Z

 #define	KEX_ECDH_SHA2_NISTP521		"ecdh-sha2-nistp521"
 #define	KEX_CURVE25519_SHA256		"curve25519-sha256"
 #define	KEX_CURVE25519_SHA256_OLD	"curve25519-sha256@libssh.org"
+#define	KEX_SNTRUP761X25519_SHA512	"sntrup761x25519-sha512"


curious: why are these defines necessary if these algs are available from upstream openssh?

These defines are still needed in upstream OpenSSH and are used in kex-names.c. The change was to move them out of the OQS template logic, since the entries were removed from generate.yml, to where the defines appear in OpenSSH.

baentsch · 2026-10-06T14:00:16Z

    struct sshbuf **);
 int	 kex_c25519_dec(struct kex *, const struct sshbuf *, struct sshbuf **);

+int	 kex_kem_sntrup761x25519_keypair(struct kex *);


so these are the upstream names? hence the removal from the generated code?

Yes that is correct.

baentsch · 2026-10-06T14:01:26Z

 	"diffie-hellman-group18-sha512," \
 	"diffie-hellman-group14-sha256," \
+	"mlkem768x25519-sha256," \
+	"sntrup761x25519-sha512," \


why not all "...@openssh.com"?

Only sntrup761x25519 needs the @openssh.com suffix. This algorithm was originally introduced by OpenSSH using the suffix before it was standardized; the plain name was added later as the standard name, and the old @openssh.com name was kept to remain interoperable. mlkem768x25519 was added after this convention and never had a vendor-suffixed predecessor, so it only needs the standard name.

baentsch · 2026-10-06T14:03:32Z

 - if `<SIG>` has L1 security, then the fork provides the methods `rsa3072-<SIG>` and `ecdsa-nistp256-<SIG>`, which combine `<SIG>` with RSA3072 and with ECDSA using NIST's P256 curve respectively.
 - if `<SIG>` has L3 security, the fork provides the method `ecdsa-nistp384-<SIG>`, which combines `<SIG>` with ECDSA using NIST's P384 curve.
 - if `<SIG>` has L5 security, the fork provides the method `ecdsa-nistp521-<SIG>`, which combines `<SIG>` with ECDSA using NIST's P521 curve.
- NOTE: OpenSSH has added support for the `ssh-mldsa44-ed25519` hybrid signature algorithm in v10.4p1, which is supported in this fork alognside OQS digital signature algorithms.


Why is this removed?

This was something I added to this PR to note the mldsa hybrid was added by OpenSSH, but when updating the upstream KEX algs I saw the "PQ Offered in OpenSSH" section and had thought it was better to just update that section with the new algorithm.

baentsch

Again various comments for understanding; I didn't see anything that would mean this cannot be merged, so feel free to go ahead with that. You've been waiting long enough for a review :-/

baentsch · 2026-10-06T14:05:41Z

+        sudo -u builder env VMCI=true WITH_OPENSSL=true bash ./oqs-scripts/build_openssh.sh
+    - name: Run tests documented to pass
      shell: netbsd {0}
+      # TODO: Investigate further ssh-tty regression test for netbsd.


worthwhile creating an issue to not have this comment drown/be forgotten?

I think the impact of the vm.yml is low enough to not drive a story for this test failure currently. I believe this is a issue with the test environment set up on netbsd and not an issue with the source code.

This ci workflow was added by OpenSSH recently and is still pretty in-progress during uplifts for integration with OQS-SSH. I can ensure this is investigated during the OpenSSH 10.6 uplift, but if it is best practice can also make a story to track this.

baentsch · 2026-10-06T14:10:14Z

-# define USE_SNTRUP761X25519	1
-/* The ML-KEM768 and ML-DSA implementations also uses C89 features */
-# define USE_MLKEM768X25519	1
+// OQS Note: Disabled upstream SNTRUP761X25519 support.


Yikes -- this means OQS code may run for these algs if a compiler option is missing. Is there any way to state which crypto lib actually delivers each algorithm?

The file here is out of date with the latest changes, this logic was inverted to behave like OpenSSH in the commit addressing preferring the OpenSSH implementation of these algorithms. The defines are set to 1 now and OQS code has been removed for these algs.

This comment did lead me to the concern where on any platform that the VLA/mixed-declarations configure checks fail, these algorithms would still be advertised despite not being available causing a negotiation that picks one of these algs to fail unexpectedly. I added guards tomyproposal.h so the algs are only advertised when defined to 1 to try and address this. If this is not in line with the original comment I can make further changes, or revert it altogether.

baentsch · 2026-10-06T14:12:02Z

+		    _PATH_HOST_MAYO_3_KEY_FILE, 0);
+		servconf_add_hostkey("[default]", 0, options,
+		    _PATH_HOST_MAYO_5_KEY_FILE, 0);
+#ifdef WITH_OPENSSL


When I see this define, I've got to ask, which lib provides the crypto (and for which algs) if OpenSSL is present? Is there any way an unwary user can determine this?

There is currently no way to see this, but it would be possible to add. One thought would be to modify the ssh -Q output to list the lib providing the crypto for the algorithm, where it might look like:

ssh -Q kex-provider mlkem768x25519-sha256 bundled-libcrux sntrup761x25519-sha512 openssh-internal ecdh-sha2-nistp256 openssl default provider ml-kem-768-sha256@oqs liboqs

or to not diverege with the upstream as much, add a new crypto-provider target (or possibly both)

ssh -Q crypto-provider ssh-mldsa-44 signature liboqs ssh-mldsa44-ed25519 signature bundled-libcrux ssh-rsa keymgmt openssl default provider mlkem768x25519-sha256 kem bundled-libcrux

Another would be to add a runtime debug/logit call to print the lib in use to the logs.

This would be a more complex change, so I'd prefer to tackle it outside the scope of this PR. Would this be in line with the comment to display the information to users? I can make a story for this and address it before completing the OpenSSH 10.6 uplift.

baentsch · 2026-10-06T14:15:13Z

 	    "                  [-m format] [-N new_passphrase] [-O option]\n"
-	    "                  [-t ecdsa|ecdsa-sk|ed25519|ed25519-sk|mldsa44-ed25519|rsa]\n"
+	    "                  [-t ecdsa|ecdsa-sk|ed25519|ed25519-sk|mldsa44-ed25519|rsa"
+		" |\n                  OQS-fork added algorithms (see README.md)"


Again the same question as above: Is there any command that would allow one to see which algs are actually available -- and which crypto lib delivers them? Is it guaranteed that the proper README is available to every user of this program / seeing this output? Wouldn't it be better to generate the real list here (if there's no other way to output the supported algs)?

My comment here is mostly covered by the response above, but the README is available in the source code for users building OQS-SSH. The complete list of algorithms are also available at runtime through ssh -Q key. I can list out the experimental OQS algorithms if that is preferred though.

baentsch · 2026-10-06T14:16:42Z

-	if (id->key != NULL && (id->key->flags & SSHKEY_FLAG_EXT) != 0 &&
+	// OQS-TODO: for now, our hybrid sig fail that test. Need to fix our formatting
+	// or update the test
+	if (!oqs_utils_is_hybrid(sign_key->type)) {


This does deserve a separate issue to ensure this test disablement is at least tracked.

Thank you for flagging this. I traced this TODO back to the 8.4 migration (3d3b064) and confirmed it is still needed to bypass the post-sign sanity check. I've opened story #201 to track and address this.

baentsch · 2026-10-06T14:18:07Z

+#define SSH_VERSION	"OpenSSH_10.4-2026-08_"

 #define SSH_PORTABLE	"p1"
 #define SSH_RELEASE	SSH_VERSION SSH_PORTABLE ", Open Quantum Safe 2026-05"


Why no OQS moniker in SSH_VERSION? Why not 2026-08 in SSH_RELEASE?

When reviewing this comment, I only found a instance of the OQS- prefix in SSH_VERSION in the OQS-v7.9 branch. I had been following what was in the v8 and v9 branches, but would be willing to add the moniker back if you and/or others think that would be clearer.

This may have been updated after the initial comment but '2026-08' is present in SSH_RELEASE now.

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

andrewyounkers

Thank you for the comments @baentsch. I have either pushed up changes requested or responded to all discussions. There are a few threads I would like further feedback on :)

andrewyounkers · 2026-10-06T17:11:19Z

 #endif /* OPENSSL_HAS_ECC */
 #endif /* WITH_OPENSSL */
 	server2->kex->kex[KEX_C25519_SHA256] = kex_gen_server;
+	server2->kex->kex[KEX_KEM_SNTRUP761X25519_SHA512] = kex_gen_server;


This change brings back in the upstream logic explicitly testing the upstream PQ algs. When reviewing this it appears to me no OQS PQ algorithms are being tested currently, so I added templating logic for this in 73875d4. If it seems reasonable I will merge in this logic, or revert if not.

andrewyounkers · 2026-10-06T17:19:57Z

 #define	KEX_ECDH_SHA2_NISTP521		"ecdh-sha2-nistp521"
 #define	KEX_CURVE25519_SHA256		"curve25519-sha256"
 #define	KEX_CURVE25519_SHA256_OLD	"curve25519-sha256@libssh.org"
+#define	KEX_SNTRUP761X25519_SHA512	"sntrup761x25519-sha512"


These defines are still needed in upstream OpenSSH and are used in kex-names.c. The change was to move them out of the OQS template logic, since the entries were removed from generate.yml, to where the defines appear in OpenSSH.

andrewyounkers · 2026-10-06T17:20:15Z

    struct sshbuf **);
 int	 kex_c25519_dec(struct kex *, const struct sshbuf *, struct sshbuf **);

+int	 kex_kem_sntrup761x25519_keypair(struct kex *);


Yes that is correct.

andrewyounkers · 2026-10-06T17:33:21Z

 	"diffie-hellman-group18-sha512," \
 	"diffie-hellman-group14-sha256," \
+	"mlkem768x25519-sha256," \
+	"sntrup761x25519-sha512," \


Only sntrup761x25519 needs the @openssh.com suffix. This algorithm was originally introduced by OpenSSH using the suffix before it was standardized; the plain name was added later as the standard name, and the old @openssh.com name was kept to remain interoperable. mlkem768x25519 was added after this convention and never had a vendor-suffixed predecessor, so it only needs the standard name.

andrewyounkers · 2026-10-06T17:52:57Z

 - if `<SIG>` has L1 security, then the fork provides the methods `rsa3072-<SIG>` and `ecdsa-nistp256-<SIG>`, which combine `<SIG>` with RSA3072 and with ECDSA using NIST's P256 curve respectively.
 - if `<SIG>` has L3 security, the fork provides the method `ecdsa-nistp384-<SIG>`, which combines `<SIG>` with ECDSA using NIST's P384 curve.
 - if `<SIG>` has L5 security, the fork provides the method `ecdsa-nistp521-<SIG>`, which combines `<SIG>` with ECDSA using NIST's P521 curve.
- NOTE: OpenSSH has added support for the `ssh-mldsa44-ed25519` hybrid signature algorithm in v10.4p1, which is supported in this fork alognside OQS digital signature algorithms.


This was something I added to this PR to note the mldsa hybrid was added by OpenSSH, but when updating the upstream KEX algs I saw the "PQ Offered in OpenSSH" section and had thought it was better to just update that section with the new algorithm.

andrewyounkers · 2026-10-06T19:56:22Z

-# define USE_SNTRUP761X25519	1
-/* The ML-KEM768 and ML-DSA implementations also uses C89 features */
-# define USE_MLKEM768X25519	1
+// OQS Note: Disabled upstream SNTRUP761X25519 support.


The file here is out of date with the latest changes, this logic was inverted to behave like OpenSSH in the commit addressing preferring the OpenSSH implementation of these algorithms. The defines are set to 1 now and OQS code has been removed for these algs.

This comment did lead me to the concern where on any platform that the VLA/mixed-declarations configure checks fail, these algorithms would still be advertised despite not being available causing a negotiation that picks one of these algs to fail unexpectedly. I added guards tomyproposal.h so the algs are only advertised when defined to 1 to try and address this. If this is not in line with the original comment I can make further changes, or revert it altogether.

andrewyounkers · 2026-10-12T15:40:06Z

-	if (id->key != NULL && (id->key->flags & SSHKEY_FLAG_EXT) != 0 &&
+	// OQS-TODO: for now, our hybrid sig fail that test. Need to fix our formatting
+	// or update the test
+	if (!oqs_utils_is_hybrid(sign_key->type)) {


Thank you for flagging this. I traced this TODO back to the 8.4 migration (3d3b064) and confirmed it is still needed to bypass the post-sign sanity check. I've opened story #201 to track and address this.

andrewyounkers · 2026-10-12T17:03:09Z

+		    _PATH_HOST_MAYO_3_KEY_FILE, 0);
+		servconf_add_hostkey("[default]", 0, options,
+		    _PATH_HOST_MAYO_5_KEY_FILE, 0);
+#ifdef WITH_OPENSSL


There is currently no way to see this, but it would be possible to add. One thought would be to modify the ssh -Q output to list the lib providing the crypto for the algorithm, where it might look like:

ssh -Q kex-provider mlkem768x25519-sha256 bundled-libcrux sntrup761x25519-sha512 openssh-internal ecdh-sha2-nistp256 openssl default provider ml-kem-768-sha256@oqs liboqs

or to not diverege with the upstream as much, add a new crypto-provider target (or possibly both)

ssh -Q crypto-provider ssh-mldsa-44 signature liboqs ssh-mldsa44-ed25519 signature bundled-libcrux ssh-rsa keymgmt openssl default provider mlkem768x25519-sha256 kem bundled-libcrux

Another would be to add a runtime debug/logit call to print the lib in use to the logs.

This would be a more complex change, so I'd prefer to tackle it outside the scope of this PR. Would this be in line with the comment to display the information to users? I can make a story for this and address it before completing the OpenSSH 10.6 uplift.

andrewyounkers · 2026-10-12T17:05:43Z

 	    "                  [-m format] [-N new_passphrase] [-O option]\n"
-	    "                  [-t ecdsa|ecdsa-sk|ed25519|ed25519-sk|mldsa44-ed25519|rsa]\n"
+	    "                  [-t ecdsa|ecdsa-sk|ed25519|ed25519-sk|mldsa44-ed25519|rsa"
+		" |\n                  OQS-fork added algorithms (see README.md)"


My comment here is mostly covered by the response above, but the README is available in the source code for users building OQS-SSH. The complete list of algorithms are also available at runtime through ssh -Q key. I can list out the experimental OQS algorithms if that is preferred though.

andrewyounkers · 2026-10-12T17:13:59Z

+        sudo -u builder env VMCI=true WITH_OPENSSL=true bash ./oqs-scripts/build_openssh.sh
+    - name: Run tests documented to pass
      shell: netbsd {0}
+      # TODO: Investigate further ssh-tty regression test for netbsd.


I think the impact of the vm.yml is low enough to not drive a story for this test failure currently. I believe this is a issue with the test environment set up on netbsd and not an issue with the source code.

This ci workflow was added by OpenSSH recently and is still pretty in-progress during uplifts for integration with OQS-SSH. I can ensure this is investigated during the OpenSSH 10.6 uplift, but if it is best practice can also make a story to track this.

The existing Focal image uses GCC 9, which cannot compile the SNOVA Round 3 AVX2 implementation currently on liboqs main. Use the OQS Jammy CI image, which is maintained by the OQS project and provides the newer compiler used by current liboqs CI. Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

djmdjm and others added 30 commits April 15, 2026 08:14

regen signature on allowed_signers file

b433d01

This was missed after the file was updated, but nobody noticed it until now.

Match case with other messages.

f2da673

account newer openssl versions in .github/setup_ci.sh

b6d4655

Test against OpenSSL 3.6.2, 4.0.0 and 4.0-stable.

713ec5c

Make ci work for OpenSSL 4 variants

eb34f95

upstream: want stdint.h here now that we've switched from u_intXX_t

00d955c

-> uintXX_t OpenBSD-Commit-ID: 6d5e80bd6f29a9db18b18beeb1cbe5423b59de44

upstream: Also show the duration of the current session through the

ca19b95

~I escape OK dtucker@ OpenBSD-Commit-ID: 695c1a09c4cc8b417a1bd3eb207b0cc7fa831c7a

upstream: correctly set extended type for client-side channels.

45b30e0

Fixes interactive vs bulk IPQoS for client->server traffic. ok job@ OpenBSD-Commit-ID: 34f5131face8d6dc4ae6955196e5fcafb3570cfe

Re-enable SHA1 sigs in OpenSSL on Cygwin for tests.

1afbd7b

Recently Cygwin imported changes from Fedora which disable SHA1 signatures by default. This breaks the unit tests (and a couple of regression tests), so set rh-allow-sha1-signatures=yes in the OpenSSL config to re-enable them.

Add tests for libressl-4.3.1.

8751cd9

Allow setting TEST_SSH_TRACE via Github.

ba110a5

Reorder steps to change perms before displaying.

6c5235c

Simplify Cygwin permissions setting.

4e0d1ae

Comment out new PAM valgrind test until debugged.

b41203e

Update OpenSSL tested versions.

2be9cec

upstream: Use supported hostkeyalgorithms specifically in

2029edd

sshd_config instead of supported key types, which is almost but not completely correct. OpenBSD-Regress-ID: 43c3b348576900f3e710bff5d6a87f0e803c5b3d

Rename obsd arm64 snapshot VM for consistency.

6185d1e

Add tracking for 10.3 branch.

b9ccca0

upstream: Clarify comment on what setting extended types for

f24dc9e

channels does OK djm@ OpenBSD-Commit-ID: fa035fb19b74571992fa3adca4396a4c572a7a8a

upstream: unveil the actual listening socket path and its directory

1bfe4ce

so it can be cleaned up at exit. Reported by / tested by David Krause, ok markus@ OpenBSD-Commit-ID: b45d740e9a63dec0fad436ed78f6912b39f0cd53

upstream: fiddle with mask after umask call and not before; avoids

1c553a1

fortify warnings on android. bz3954 OpenBSD-Commit-ID: 82224426b2ee989c68f305caa50aa3d3b4993a84

vm.yml: fix solaris PAM tests

7ab5e40

Add missing SSHD_CONFOPTS="UsePam yes" to the solaris PAM test step so it actually tests PAM functionality instead of re-running the default tests with a PAM-enabled binary.

Remove 9.9 and 10.0 branches from build status page.

5fa60ae

skip ("#if 0") strvisx and stravis

328993c

we don't use the in OpenSSH and some compilers throw warnings compiling them that break -Werror

Add RUN_ONLY_PLATFORM to run a subset of tests.

cb654c2

Add Solaris 11.4-clang-19 test.

05af655

Only run t-exec when re-testing with PAM.

f9d62ea

There's no point rerunning unit tests.

Improve Solaris PAM tests.

6296749

- Set up and run tests with SUDO. - Set random password to use for password & kbdint auth tests. - Only run t-exec when re-testing with PAM, don't rerun unit tests. - When testing PAM builds, test with and without UsePAM.

djmdjm and others added 12 commits July 6, 2026 17:55

upstream: openssh-10.4

0210c7c

OpenBSD-Commit-ID: ce7b0749e5139c70410ee92a13d368d7d34262b5

crank version numbers

0227fe4

depend

449d25b

autogenerated files for release

e8dd756

upstream: fix GSSAPI option names, that I somehow screwed up while

823ad00

refactoring servconf.c bz3974 patch from Colin Watson OpenBSD-Commit-ID: be39ad3dbe36d9ecdb86f3811da5dfbdc9bcb1e6

Re-allow PAMServiceName inside a Match block.

6789420

This is documented to be allowed, and was up until 10.4p1 when a transcription error in the config handling rework reverted it to global-only, ie not allowed inside Match. bz#3987.

Merge remote-tracking branch 'openssh/V_10_4' into feature/openssh_10…

54ef3d4

…_4_uplift

merge conflict resolutions

1dc4dc1

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

update readme to include OpenSSH 'ssh-mldsa44-ed25519' implementation

1ef3c3a

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

address regression failures

11d631a

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

bring in applicable openssh changes to vm.yml

5e43328

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

andrewyounkers requested review from alharrison and dstebila August 11, 2026 16:36

andrewyounkers self-assigned this Aug 11, 2026

andrewyounkers marked this pull request as ready for review August 11, 2026 19:37

baentsch reviewed Oct 6, 2026

View reviewed changes

baentsch approved these changes Oct 6, 2026

View reviewed changes

andrewyounkers mentioned this pull request Oct 12, 2026

Hybrid signatures bypass sshkey_check_sigtype post-sign validation #201

Open

andrewyounkers added 2 commits October 12, 2026 13:37

Test experimental OQS algorithms in test_kex

73875d4

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

Remaining pr comments

a2de113

Signed-off-by: Andrew Younkers <ayounkers44@gmail.com>

andrewyounkers commented Oct 12, 2026

View reviewed changes

Conversation

andrewyounkers commented Aug 11, 2026

Uh oh!

baentsch commented Aug 12, 2026

Uh oh!

andrewyounkers commented Aug 12, 2026

Uh oh!

andrewyounkers commented Aug 12, 2026

Uh oh!

alharrison commented Sep 25, 2026

Uh oh!

baentsch commented Sep 25, 2026

Uh oh!

andrewyounkers commented Sep 28, 2026

Uh oh!

baentsch left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewyounkers Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewyounkers Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baentsch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewyounkers Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewyounkers Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewyounkers left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andrewyounkers Oct 6, 2026 •

edited

Loading

andrewyounkers Oct 6, 2026 •

edited

Loading

andrewyounkers Oct 12, 2026 •

edited

Loading

andrewyounkers Oct 12, 2026 •

edited

Loading

andrewyounkers left a comment •

edited

Loading

andrewyounkers Oct 6, 2026 •

edited

Loading

andrewyounkers Oct 6, 2026 •

edited

Loading

andrewyounkers Oct 12, 2026 •

edited

Loading

andrewyounkers Oct 12, 2026 •

edited

Loading